Semantic HTML Tags and Their Introduction
Semantic tags clearly describe the meaning of their content to both browsers and developers. Instead of just telling the browser how something looks, they convey the role or purpose of the content. Many were introduced in HTML5 (2014 W3C Recommendation), while a few existed earlier.
<mark> (HTML5) – Highlights or marks text for reference.
<time> (HTML5) – Represents dates and times in a machine-readable way.
<abbr> (HTML4) – Defines abbreviations/acronyms.
<cite> (HTML4) – Reference to a creative work (book, article, etc.).
<code> (HTML4) – Represents inline code snippets.
<em> (HTML4) – Emphasized text, usually italicized.
<strong> (HTML4) – Important text, usually bold.
<q> (HTML4) – Short inline quotation.
<label> (HTML4) – Semantic association with form controls.
<bdi> (HTML5) – Bi-directional text isolation.
<wbr> (HTML5) – Word break opportunity for better text rendering.
Most of the modern layout-related semantic tags like <header>, <footer>, <article>, <aside>, <nav>, <main>, <figure>, and <figcaption> were introduced with HTML5 (2014). Older semantics like <em>, <strong>, <cite>, <code>, <blockquote>, etc., have existed since HTML4 (1997).
You're building a simple blog page. Which semantic tags would you use for the header, navigation, article content, and footer, and why?
If you accidentally use a <div> instead of a semantic tag like <nav>, what impact could that have on screen readers or SEO?
Your team inherited a legacy site that uses <div> everywhere. How would you refactor it to use HTML5 semantic tags, and what challenges might you hit with older browsers?
During QA a screen reader isn't announcing the main content region. Which semantic tag should be present, and how would you confirm it's used correctly?
We need to improve accessibility and SEO for a large e‑commerce platform with thousands of pages. How would you design a migration strategy to introduce semantic tags across the site while minimizing risk and performance impact?
Explain how the introduction timeline of tags like <header> and <section> influences a progressive‑enhancement approach for users on older browsers.
Our company maintains a shared component library used by multiple product teams. How would you standardize the use of semantic tags in that library, and what governance processes would you put in place to ensure consistency over years?
Consider a legacy monolithic app that must still support IE11. How would you balance the need for modern semantic markup with older‑browser constraints, and what long‑term architectural decisions would you recommend?